…e.test.ts

Documents the *.live.test.ts convention in AGENTS.md (a 4th test category
alongside unit/integration/e2e): black-box CLI subprocess tests executed by
the cli-e2e-ci harness against a real supabox stack. Clarifies how
local-dev-stack commands like stop/status fit this pattern despite never
calling the Management API — they only need the real Docker daemon the
cli-e2e-ci runner also provides, so they reuse the existing describeLive
gate rather than a dedicated one.

Adds stop.live.test.ts and status.live.test.ts, each spinning up a real
local Docker stack (init -> start, excluding the heaviest services) in an
isolated temp directory and verifying the command under test against the
real containers, with best-effort cleanup on every path.

…0O86N3Lyo)

Go's status.toValues() gates each service on `--exclude` matching either
the container id or the Docker image's short name (ShortContainerImageName).
The TS port only checked container ids. Port the short-name extraction and
check it against the same default images the embedded Dockerfile manifest
already provides, since the relevant Go config fields (KongImage, Image,
etc.) all carry `toml:"-"` and are never user-overridable.

…us-commands

# Conflicts:
#	apps/cli/docs/go-cli-porting-status.md

…6N4wLa, PRRT_kwDOErm0O86N4wLu)

Go registers both --override-name and --exclude as pflag StringSliceVar
(cmd/status.go:36-37), which CSV-splits each occurrence and accumulates
across repeats. The TS flags only handled repetition, so a single
comma-separated value like `--exclude kong,auth` produced one malformed
entry instead of two. Reuses the shared legacyParseStringSliceFlag already
applied to sso/postgres-config for the same StringSlice parity gap.

…6N4wL1)

Go's Config.Validate fails config-load when auth.jwt_secret is set but
shorter than 16 characters (pkg/config/apikeys.go:45-47), before any command
can render output. The TS resolver accepted any non-empty value and signed
ANON_KEY/SERVICE_ROLE_KEY with it, letting `status -o env/json` succeed and
print keys for a config the Go CLI and local stack both reject.

… PRRT_kwDOErm0O86N4wLx)

Go's config loader binds Viper with SetEnvPrefix("SUPABASE") + AutomaticEnv()
(pkg/config/config.go:529-535), so SUPABASE_AUTH_JWT_SECRET/PUBLISHABLE_KEY/
SECRET_KEY/ANON_KEY/SERVICE_ROLE_KEY override the corresponding config.toml
value at higher precedence. legacyResolveLocalConfigValues only read the
decoded config object, so a local stack started with those env overrides
had `status` print keys that didn't match the running Auth service. Scoped
to exactly the 5 auth fields this module reads, not a general
@supabase/config port of Viper's AutomaticEnv.

…ed (review: PRRT_kwDOErm0O86N4wLk)

Go's generateJWT signs anon/service_role with the first key in
auth.signing_keys_path (RS256/ES256) instead of HMAC when that file
resolves to a non-empty JWK array (pkg/config/apikeys.go:76-113). The TS
resolver only ever HMAC-signed with jwt_secret. Ports GenerateAsymmetricJWT
via legacyGenerateAsymmetricGoJwt (RFC 7517 JWK -> Node crypto private key,
ieee-p1363 signature encoding for ES256's raw r||s format) and wires it
into legacyResolveLocalConfigValues, which now needs workdir to resolve a
relative signing_keys_path against <workdir>/supabase.

Go's jwkToRSAPrivateKey/jwkToECDSAPrivateKey reject a JWK whose kty doesn't
match its claimed alg, and an EC key whose curve isn't P-256
(pkg/config/auth.go). legacyGenerateAsymmetricGoJwt only checked alg, so an
EC key forged with alg: RS256 (or a non-P-256 curve claimed as ES256)
signed "successfully" and produced a spec-invalid token that silently
fails verification instead of raising an error. Found independently by the
security and DX reviewers in review-changes.

…tusValues twice

status.handler.ts called legacyStatusValues twice per invocation (real
values, then pretty-mode values with an empty override map) — only the
first call was wrapped in Effect.try. With signing_keys_path support this
doubled file I/O + JWT signing on every text-mode run, and left the second
call able to throw an uncaught exception if it ever diverged from the
first. Splits legacyStatusValues into legacyResolveStatusState (the
throwing half: local config resolution + gating) and
legacyStatusValuesFromState (pure name remapping), so the handler resolves
state once, guards it once, and reuses it for both value maps.

…ration coverage

Go's Config.Validate fails a bad auth.signing_keys_path with "failed to
read signing keys: %w" (open failure) or "failed to decode signing keys:
%w" (parse failure) (pkg/config/config.go:1059-1062). The TS port let
readFileSync/JSON.parse's raw Node error text through unwrapped instead.
Also adds status.integration.test.ts coverage for the SUPABASE_AUTH_* env
override and asymmetric-signing-key behaviors, which previously only had
unit-level coverage on the pure resolver.

…e2e shard 1/3)

Go prints this line via an unconditional, immediate fmt.Fprintln before any
Docker call runs (docker.go:97), routed straight to stdout in non-interactive
mode (tea.go's fakeProgram). The TS port gated it behind the shared
output.task spinner's 200ms debounce, so the line was silently dropped
whenever the underlying Docker calls resolved faster than that threshold —
exactly what happens against the mocked/replayed Docker CLI in the e2e
harness. Printing it directly via output.raw removes the race entirely.

…ity request logs (ci: e2e shard 1/3)

stop/status parity comparisons were failing on request-log mismatches that
reflect nothing about CLI behavior: the real docker CLI issues a fresh
HEAD /_ping handshake before every subprocess invocation (Go's SDK pings
once per command via a persistent client), and negotiates its own API
version segment into the URL path (/v1.51/ vs /v1.53/) based on the
installed docker CLI/daemon, not anything the command controls. Strip both
before comparing so parity reflects the actual Docker operations performed
rather than client plumbing, mirroring the equivalent normalization already
used for fixture matching in apps/cli-e2e/src/server/placeholder.ts.

…s (review: PRRT_kwDOErm0O86N7ctR)

Go's Viper binds SetEnvPrefix("SUPABASE") + AutomaticEnv() over every
config field via UnmarshalExact's struct walk (pkg/config/config.go:531-535,
698-705), including the plain-string Auth.SigningKeysPath field
(pkg/config/auth.go:164) — not just the 5 auth fields this module already
wrapped with envOverride. Load() resolves that override before Validate()
opens and parses the JWK file (config.go:735-745, 1059-1062), so an
env-only SUPABASE_AUTH_SIGNING_KEYS_PATH was silently ignored and status
fell back to HMAC-signed keys the running Auth service would reject.

… status (review: PRRT_kwDOErm0O86N7ctY)

Go's Config.Load runs loadNestedEnv (supabase/.env and .env.local via
godotenv.Load, which never overrides an already-set var) before
loadFromFile wires up Viper's AutomaticEnv (pkg/config/config.go:735-745,
528-535) — so an env-file-only SUPABASE_PROJECT_ID overrides config.toml's
project_id too, not just an ambient shell export. Both handlers only read
process.env directly, missing that middle step: an env-named stack could be
left running by stop, or status could target the wrong container.

@supabase/config's loadProjectEnvironment already implements the same
"ambient wins over .env/.env.local" layering (used today only for env()
interpolation inside config.toml), so both handlers now resolve
SUPABASE_PROJECT_ID through it instead of process.env directly, and pass
the same resolved environment into loadProjectConfig so the .env files
aren't parsed twice. Falls back to process.env directly when no
supabase/config.toml exists anywhere (loadProjectEnvironment resolves to
null in that case), preserving the existing ambient-only behavior for that
scenario.

The identical gap in LegacyCliConfig.projectId (used by several other
already-ported commands) is out of scope here and left for a follow-up.

…us-commands

# Conflicts:
#	apps/cli/docs/go-cli-porting-status.md
#	apps/cli/src/legacy/commands/seed/buckets/buckets.handler.ts

…ets hoist merge

develop's db push/reset/start port (#5715) hoisted the seed-buckets
config load out of buckets.handler.ts and into the shared
legacySeedBucketsRun (also used by db reset --local), which
superseded the inline goViperCompat opt-in added on this branch.
Carry the opt-in over to the new call site so seed buckets and
db reset --local keep Go-parity config semantics.

…e quality)

Collapses a .pipe() call back to oxfmt's canonical single-line form;
introduced by the develop merge conflict resolution and left unformatted.

…ting scheme (review: #PRRT_kwDOErm0O86OsZMu)

Go's hookConfig.validate calls url.Parse before the scheme switch
(pkg/config/config.go:1497-1499) and rejects a malformed URI (e.g. an
unterminated IPv6 host like http://[::1) before status/stop reach Docker.
The TS validator only regex-extracted a scheme prefix, so any http:/https:
prefix was accepted regardless of the rest of the URI. Reuses the existing
legacyGoUrlParse port (already used for studio.api_url) instead of the
scheme regex.

…PI keys (review: #PRRT_kwDOErm0O86OrzAU)

Go's config.Secret fields (auth.jwt_secret/publishable_key/secret_key/
anon_key/service_role_key, pkg/config/auth.go:181-185) are decrypted by
DecryptSecretHookFunc unconditionally during UnmarshalExact
(pkg/config/secret.go:30-73), failing config load on an undecryptable
value before status/stop continue. @supabase/config's schema only tags
these fields for later Redacted wrapping and never decrypts them, so the
status/stop resolver was using an "encrypted:..." value as literal (wrong)
key material, and never failed on an undecryptable one. Reuses the
existing eciesjs-based decrypt primitives from legacy-vault-decrypt.ts
(already used by the db/migration config loader for the same Go hook).

…ection (review: #PRRT_kwDOErm0O86Ossk3)

Go's -o/--output is a root PersistentFlags() enum (cmd/root.go:330) every
subcommand inherits, so "stop -o csv"/"-o table" is rejected by pflag at
parse time even though stop.RunE never reads the value itself. The doc
claimed Go has no such flag and that TS accepting an unknown value was a
harmless divergence — in fact stop.command.ts already rejects the same
values via withLegacyCommandInstrumentation's default outputFormats gate,
matching Go exactly. No behavior change, just correcting the doc.

…: #PRRT_kwDOErm0O86PMyg7)

Go's flags.LoadConfig swallows any Config.Load error non-fatally
(internal/secrets/set/set.go:22-24), including the invalid-format error
Config.Validate raises for a bad remotes.*.project_id
(pkg/config/config.go:996-1001). The TS handler only recovered from
DuplicateRemoteProjectIdError, so a malformed remote block could abort an
otherwise-valid secrets set; now InvalidRemoteProjectIdError is handled the
same way.

…review: #PRRT_kwDOErm0O86OsZM5)

Go's external.validate() (pkg/config/config.go:1419-1451) validates every
enabled auth.external provider, including arbitrary/unmodeled names, since
Go's External field is a genuine map[string]provider. @supabase/config's
schema only models ~20 known providers and silently drops anything else at
decode time, so status/stop (which decode through that schema) could accept
a misconfigured unmodeled provider Go rejects. auth.external was already
D-only (legacy-db-config.toml-read.ts) per legacy-config-validate.ts's
module header; this ports the identical inline raw-document check to L
(legacy-local-config-values.ts), run after the shared
legacyValidateResolvedConfig call per the documented sms/external-vs-
third_party ordering tradeoff.

…l providers (review: #PRRT_kwDOErm0O86OsslE)

Go's (s *sms) validate() (apps/cli-go/pkg/config/config.go:1348-1410) is a
boolean switch that validates ONLY the first enabled provider in a fixed
priority order (twilio, twilio_verify, messagebird, textlocal, vonage) — a
later enabled-but-incomplete provider is never inspected. The sms schema
instead attached an independent requiredWhenEnabled check to each provider
sub-struct, validating every enabled provider at decode time, so a stale
secondary [auth.sms.*] block Go silently ignores could make native
status/stop reject a config Go accepts. Replaced the five per-provider
checks with a single struct-level check implementing Go's switch-priority
semantics.

… gaps in status/stop config resolution

Four related Go-parity gaps in legacyResolveLocalConfigValues, all variations
on values not being re-checked against the post-env-override state before
validation runs (continuing the pattern fixed in 08ed337 for hook/captcha/
passkey/smtp):

- project_id: Go's mergeDefaultValues merges sanitizeProjectId(filepath.Base(
  cwd)) in as a viper default BEFORE config.toml is merged (config.go:690-699,
  via Eject), so c.ProjectId is never Go's zero value by the time Validate
  runs. A workdir whose basename sanitizes to "" (e.g. "!!!") therefore fails
  config loading in Go even with no project_id key in the file at all; this
  resolver only used the raw (unsanitized, non-defaulted) config value,
  silently passing `undefined` through and skipping the check entirely.

- auth.email.notification/template: SUPABASE_AUTH_EMAIL_NOTIFICATION_<NAME>_
  ENABLED/_CONTENT_PATH and SUPABASE_AUTH_EMAIL_TEMPLATE_<NAME>_CONTENT_PATH
  overrides now apply before deciding whether/what content_path to validate,
  instead of only reading the schema-decoded (pre-override) value.

- auth.sms: @supabase/config's sms schema implements Go's provider-switch
  validation (cac1e5f) but only at decode time, before this shell's env
  overrides are resolved. Added validateAuthSmsProviders, which re-runs the
  same fixed-priority switch against the raw document with
  SUPABASE_AUTH_SMS_<PROVIDER>_* overrides applied, so an env-only enabled
  provider is still checked.

- auth.external: SUPABASE_AUTH_EXTERNAL_<NAME>_ENABLED/_CLIENT_ID/_SECRET
  overrides now apply before validateAuthExternalProviders' required-field
  checks, covering known and unmodeled provider names alike.

(review: #PRRT_kwDOErm0O86POG5r, #PRRT_kwDOErm0O86POG5w, #PRRT_kwDOErm0O86POG5z, #PRRT_kwDOErm0O86POG54)

…atus/stop validation (review: #PRRT_kwDOErm0O86PQqa2)

Go's Viper setup (`ExperimentalBindStruct` + `SetEnvPrefix("SUPABASE")` +
`AutomaticEnv()`, `pkg/config/config.go:580-586`) binds every leaf field of
the config struct to a `SUPABASE_*` env override before `Config.Validate`
runs. `Auth.MFA` and `Auth.ThirdParty`'s provider structs are value-typed
(never `nil`, `auth.go:191-198,317-320`), so — unlike `Auth.Hook`/smtp's
pointer-typed fields, which need TOML-presence gating — these overrides
apply unconditionally, even when the section is absent from both the file
and the default template (e.g. `[auth.mfa.web_authn]` and
`[auth.third_party.workos]`).

`legacyResolveLocalConfigValues` read `config.auth.mfa.*` and
`config.auth.third_party.*` straight off the decoded TOML with no env
override, so e.g. `SUPABASE_AUTH_MFA_TOTP_ENROLL_ENABLED=true` or
`SUPABASE_AUTH_THIRD_PARTY_FIREBASE_ENABLED=true` could change Go's
validation outcome while this port silently ignored them. Wires both blocks
through `legacyEnvOverrideBool`/`envOverride`, matching the existing
hook/smtp precedent in the same file.